docs(setup): the AI Copilot checklist says what Setup actually ships - #1622
Merged
Conversation
Section 14 of the admin setup checklist told an admin to "Confirm the AI Copilot is enabled (Setup → AI)", to "Choose which skills to enable" and to "Configure data sensitivity rules". Setup ships no AI group, and neither of the other two screens exists. All three are resolved against the installed platform (@objectstack/* 17.3.0), the way test/docs-setup-navigation-names.test.ts builds its roster. No enable surface: the `ai` settings namespace behind Configuration → AI & Embedder has no master switch — its toggles are title generation, traces and prompt logging, its gestures are Test connection, Test embedder and Reset to environment defaults. The beta AI Assistant toggle under Configuration → Feature Flags ships off, and its key `ai_enabled` occurs nowhere in the installed platform but its own manifest and its four locale labels. What decides whether the Copilot answers is the provider, which defaults to Memory (echo — testing only), so the item became that check plus a denial. No per-skill enable surface: no Setup entry names skills and none of the eleven settings namespaces carries a skill key. `active` is metadata (default true, declared nowhere in src/skills), and the roster comes from allSkills — an app change. The item now points at Studio → AI → Skills for the roster and says the set is decided in the app. No AI redaction screen: the platform's only redactFields is an object's publicSharing block, which strips fields from share-token responses and has nothing to do with the Copilot. What limits the Copilot is field-level security, which administration/sharing-and-security already states is enforced for the Copilot like everywhere else, so the item sends the reader there. Every surviving path is bold, the shape the navigation guard's rule 2 resolves live — the parenthesised prose is why this line was invisible to both of its rules. zh-Hans uses the zh-CN language-pack labels; zh-Hant spells platform navigation in English. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018xtjdpZFjgWh4Ad9Wcx68J
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
os-steve
marked this pull request as ready for review
September 6, 2026 00:50
os-steve
pushed a commit
that referenced
this pull request
Sep 6, 2026
`reference/faq` line 116, under "The Copilot won't answer about a specific customer", told admins they could "block the Copilot from referencing flagged accounts (e.g., VIP, in litigation)" and that "The Copilot says so explicitly". No such control ships, in any of the three faces. Resolved against the installed platform (@objectstack/* 17.3.0): none of the eleven shipped settings namespaces carries a redaction or sensitivity key, no Setup entry names redaction, sensitivity or masking in any of the four shipped locales, and src/ carries no VIP, litigation or AI-exclusion flag for anything to read — so the promised "says so explicitly" behaviour has nothing to trigger it. The platform's only redactFields is an object's publicSharing block, spec'd as the fields stripped from share-token responses; knowledge_article.object.ts is this repo's only user, for exactly that. Nothing leaks — the danger runs the other way. An admin who believes flagged-account blocking is available to switch on may never configure the control actually doing the work, so the line becomes a denial that hands the reader field-level security: the Copilot reads as the signed-in user, so a field masked on their profile never reaches it. That is what administration/sharing-and-security already states, FLS being enforced for the Copilot as for list views, reports and the API. Deliberately not written as per-account blocking — FLS is permission-shaped visibility, and conflating the two is the defect being removed. The same claim in checklist form was corrected on administration/setup section 14 (#1622); both pages now deny it in one voice and point at one page. Fixes #1623 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018xtjdpZFjgWh4Ad9Wcx68J
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1614
Section 14. AI Copilot of the admin setup checklist told an admin to "Confirm the AI Copilot is enabled (Setup → AI)", to "Choose which skills to enable" and to "Configure data sensitivity rules — which fields the Copilot must redact". Setup ships no
AIgroup, and neither of the other two screens exists. All three are resolved together, against the installed platform (@objectstack/* 17.3.0), the waytest/docs-setup-navigation-names.test.tsbuilds its roster —SETUP_APP.navigation+SETUP_NAV_CONTRIBUTIONS+SetupAppTranslations, across the four shipped locales.The three measurements
1. Nothing enables the Copilot — and the one control that looks like it does is not it.
Setup's nine groups are Overview, Apps, People & Organization, Access Control, Approvals, Configuration, Diagnostics, Integrations, Advanced;
AIis a Studio group holding Agents / Tools / Skills. Theaisettings namespace behind Setup → Configuration → AI & Embedder carries no master switch: its only toggles are Auto-summarize conversation titles, Record traces and Log full prompts, and its only gestures are Test connection, Test embedder and Reset to environment defaults — matching what #1591 measured.The candidate switch is real:
feature_flags.ai_enabled, labelled AI Assistant under Setup → Configuration → Feature Flags, tenant-scoped, marked beta, defaultfalse, help text "Enables the in-app AI assistant panel", env-pinnable asOS_FEATURE_FLAGS_AI_ENABLED. It is still not the Copilot's switch: the keyai_enabledoccurs nowhere in the installed@objectstack/*tree except its own manifest and its four locale label bundles, and the shipped console computes assistant availability from the agent roster rather than from any feature flag. What does decide whether the Copilot can answer is the provider, whose manifest default is Memory (echo — testing only) — it replays the question instead of answering it.So the item became that check plus a denial, not a redirect to a plausible-looking screen. It was not deleted (the route the dispatch offered): with the default provider there is a real Day-5 thing to do, and the checklist genre wants the thing to do.
2. There is no per-skill enable surface.
No Setup entry names skills, and none of the eleven settings namespaces (
sys,auth,mail,sms,branding,feature_flags,storage,ai,knowledge,localization,company) carries a skill key.activeis skill metadata:SkillSchemadefaults it totrue, none of the sixsrc/skills/*.skill.tsfiles declares it, and the roster comes fromallSkills— whichcontent/docs/customization/ai-skillsalready documents as an app change. The item now points at Studio → AI → Skills for the roster and says the set is decided in the app rather than picked at setup time.Not settled, and reported as unsettled rather than asserted: whether Studio's
metadata:resourcebrowser lets an admin flipactiveon a package-provided skill. The wording holds either way — Studio is not Setup, and the roster still comes from the app.3. There are no AI sensitivity or redaction rules to configure.
The only
redactFieldsthe platform defines belongs to an object'spublicSharingblock — "Field names removed from records served via a share token" — whichcrm_knowledge_articleuses for share links and which has nothing to do with the Copilot. No settings namespace and no Setup entry mentions redaction or sensitivity. What limits what the Copilot may read is field-level security, whichadministration/sharing-and-securityalready states in its own words: FLS is enforced in list views, reports, the API and the AI Copilot alike, and the Copilot reads as the signed-in user. The item now sends the reader there.Shape
The shape is the one ruled on #1402 / PR #1401 and again on #1591 / PR #1616: say what actually ships, put a denial where nothing does, redirect only to a path that resolves live. Every surviving path is written in bold — the free half of the fix. This instance's citation was bare parenthesised prose, invisible to both of #853's rules: rule 2 matches a bold
**App → …**citation, and rule 1 cannot banAI, which is a real Studio label. No guard was extended and none was built.Ablation — committed first, mutation proved on disk, restored byte-identically to the
HEADblob (fe9da43c…before,7612af69…mutated,fe9da43c…after;git diff HEADempty):**Setup → Configuration → AI & Embedder**citations insetup.mdxwith**Setup → AI → AI & Embedder**turnstest/docs-setup-navigation-names.test.tsred, exit 1, naming the file and the segment:content/docs/administration/setup.mdx: 'Setup → AI'That is what the bolding buys: the same wrong claim that shipped invisibly for months is caught by name once it is written in the shape rule 2 parses. It is also why no bolded path here is one that fails to resolve — the first segments are
Configuration(a Setup group) andAI(a Studio group), in every face.Locale conventions
/zh-Hans/and/zh-Hant/prefixes on every site-absolute link (docs(i18n): keep the locale prefix on twelve links in the Chinese pages #1599).Gates
Full
pnpm verifychain, run script by script in this worktree at95acfe09:pnpm validatepnpm typecheckpnpm lintpnpm lint:i18n-gatei18n/missing-*issues"pnpm hygienepnpm hygiene:tokenspnpm buildpnpm testWhat no gate reads
The prose itself.
link-check.ymlwakes on.mdxbut runsfile-extension: '.md'withcheck-modified-files-only, so it opens none of the three pages — only the changeset, which carries no site-absolute links. A green there says nothing about these edits. The evidence for the paths is the roster read above, not a check mark.Scope
content/docs/administration/setup.mdx+.zh-Hans.mdx+.zh-Hant.mdx, section 14 only, plus one changeset. Nosrc/, notest/**, no new guard, no other section.Generated by Claude Code